fix(automations): remove confirmation can open with focus on body text, and Systems and Automations fixture checks fail during re-renders - #2146

Related: #2124, #2132

What Problem This Solves

Fixes: the Automations remove confirmation can open with keyboard focus on its body text instead of Cancel, and the Systems and Automations mock Gateway UI tests fail intermittently on main while those pages re-render.

User Impact

User impact: when you remove an automation, the confirmation now always opens with keyboard focus on Cancel, the safe choice it was designed to focus, instead of sometimes on the body text. Contributors also get fewer false CI failures in the "Mock Gateway application and compatibility tests" job.

Why This Change Was Made

Automations remove confirmation (product fix). Before this change, AutomationsRoot queued a low-priority "focus Cancel" call from the dialog's Opened event. WinUI runs its own initial-focus step, which picks the first focusable element (the selectable body text). Whichever ran last won, so focus sometimes stayed on the body. CI caught this as "Timed out waiting for Cancel receives destructive initial focus" (run 43323497743, attempt 2).

The new DialogInitialFocus helper redirects the first focus that enters the dialog to Cancel inside WinUI's own focus step, the same approach SystemsPageView already uses. When a dialog opens right after another closes, Opened and even the first focus can arrive before the Cancel button exists. The helper then retries after each layout pass until Cancel takes focus. Later focus moves are never redirected.

Systems and Automations UI tests (test fix). #2124 made these tests check that every UI element they find belongs to the app's own window. Some of those checks ran inside polling waits as one-shot asserts. While a page re-renders, an element found a moment earlier can be torn down before the ownership check finishes, so the check could not prove ownership and the test failed. It should have looked again.

Ownership now has three results:

• Owned: proven to belong to the app's window.
• Unproven: no contrary evidence, but not provable yet, for example a detached or vanished element. Polling waits keep polling.
• Foreign: positive evidence of another process or window. This still fails immediately.

IsOwnedDescendant still returns true only for Owned, so the ownership guarantee from #2124 is unchanged. The Systems capture helper also re-finds its controls inside its wait, instead of reusing elements that a re-render may have replaced.

The changes add no retries of actions, sleeps, fixed settle counts, skips, or weaker assertions.

Evidence

• Automations focus race, deterministic negative: with the new redirect disabled, so Cancel focus comes only from a queued call after Opened as before, the new DialogInitialFocusTests fails with "confirmation-0: first focus after Cancel was realized went to TextBox". With the fix it passes.
• Opened can precede the dialog's controls: diagnostics showed Opened firing with zero visual children before the focus step; on the CI runner this happens even on the first open. Before the retry-until-realized change, the body kept focus in about 1 of 25 quick reopens. The test therefore never samples focus at Opened. It records every focus change through the dialog's own GettingFocus and opens 11 confirmations per run, each right after the previous one closed. For each one it requires:
  • the first focus inside the dialog once Cancel exists is Cancel;
  • Cancel keeps focus;
  • nothing else inside the dialog takes focus afterwards.
    It also requires that a later focus move to the body is not taken back.
• Ownership rules: NativeUiOwnershipClassificationTests checks Owned, Unproven and Foreign deterministically over synthetic ancestry, including:
  • missing evidence never hiding foreign evidence;
  • partial reads keeping a foreign process id;
  • an owner changing identity mid-walk.
    The existing live two-window test now also asserts Foreign for every rejection case.
• SystemsDaily root cause: CI receipts (run 43191056837 and others) and local instrumented runs showed the ownership walk transiently unprovable during re-render, plus ElementNotAvailableException while saving a capture of re-rendered stat tiles. The same pattern was reproduced locally in Automations TryPageScrollPeer ("page marker must belong", Dark theme).
• Review: dual-model Hanselman review (Claude Opus 5.5 and GPT-6 Astra, high effort), three rounds. All consensus findings and all MEDIUM findings are fixed; see Real Behavior Proof for the open LOW notes.

Change Type

• Bug fix
• Feature
• Refactor
• Docs or instructions
• Tests or validation
• Security hardening
• Chore or infrastructure

Scope

• Tray or WinUI UX
• Windows node capability
• Local MCP or winnode
• Gateway, connection, or pairing
• Setup or onboarding
• Permissions, privacy, or security
• Tests, CI, or docs

Required proof pools

• none: the product change is limited to keyboard focus in the Automations confirmation dialog. It is proven by native in-process and mock Gateway UI tests that CI runs directly; no custom capacity-dependent Windows proof applies.

Validation

All runs were local on Windows x64 at 175% DPI, with isolated app and test profiles. Metadata for the real %APPDATA%/%LOCALAPPDATA%\OpenClawTray was unchanged after every run. Fixture runs used OPENCLAW_RUN_KEYBOARD_PROOF=1 and screenshots, matching CI.

Final source (hashes recorded before the commit; this commit is that source rebased onto origin/main ee8edbc with no conflicts):

Full fixture UI suite (filter Category=GatewayFixture&KeyboardProof!=Required, run directly because the script's 1800 s cap is shorter than the ~31 min local run at 175% DPI), on the final source together with the separate pointer/capture PR's test change: 122/124 passed. The two failures are in tests this PR does not change:

• Automations_HeroWashScrollsWhileTheBackplateStaysAnchored(Dark): "Timed out waiting for theme choice". The theme ComboBox did not open after a one-shot UIA Expand() in the unchanged SelectAppThemeAsync. A rerun passed 3/3.
• ReconnectKeepsDefinitelyUnsentQueuedMessageFailedAndVisible: MCP app.chat.send "Request canceled". This test is unchanged from main, and it also fails on main's own test code locally (2 of 3 reruns). Reported separately as a pre-existing issue.

After rebasing onto origin/main ee8edbc (#2141):

• .\scripts\validate-test-timing-patterns.ps1: "Test timing pattern ratchet passed." No baseline-lowering suggestion.
• Rebuilt the app and UI tests. Affected tests: dialog and ownership 3/3, Automations 2/2, SystemsDaily 2/2.

Closeout on the rebased commit:

• ./build.ps1: all builds succeeded.
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore: 5849 passed, 0 failed, 29 skipped.
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore: 6402 passed, 0 failed.

Real Behavior Proof

• Environment tested: local Windows x64 desktop, 175% DPI, isolated app and test profiles, mock Gateway fixture.
• PR head or commit tested: 7f120bc (on ee8edbc). Product and fixture changes are unchanged since 8b8c875. The repeat runs used the identical pre-rebase source, and the affected tests were rerun after the rebase. The dialog test was revised in 7f120bc and rerun 10/10 together with its negative.
• Exact steps or command run: dotnet test tests/OpenClaw.Tray.UITests -c Debug -r win-x64 -p:DevBuild=false --no-build --filter <test>, with the fixture environment from scripts/test-gateway-fixture.ps1 (OPENCLAW_RUN_GATEWAY_FIXTURE_UI=1, OPENCLAW_RUN_KEYBOARD_PROOF=1, screenshots on).
• Evidence after fix: native focus assertions in DialogInitialFocusTests, plus the Automations_ScopesToAgentsAndCoversMainStates remove step, which waits for UI Automation to report keyboard focus on the dialog's Cancel button.
• Observed result: see Validation.
• Screenshot or artifact links verified? (Yes/No/N/A): N/A (local artifacts only).
• Not verified or blocked:
  • First-attempt CI on 8b8c875 (run 43368190358) failed only in this PR's own new dialog test. It sampled focus at Opened, and on the runner Opened fired before Cancel existed. 7f120bc fixes the test; the product code is unchanged. The Mock Gateway job, which includes SystemsDaily and the Automations remove step, passed on that run. CI for 7f120bc is pending.
  • Open one-model LOW review notes, not applied:
    • Reaching the ancestry depth limit returns Unproven, not a clear failure.
    • AssertUnchanged still runs after the Systems capture wait.
    • The focus helper keeps Pending while a dialog without a focusable Cancel stays open.

Security Impact

• New permissions or capabilities? (Yes/No): No
• Secrets or tokens handling changed? (Yes/No): No
• New or changed network calls? (Yes/No): No
• Command or tool execution surface changed? (Yes/No): No
• Data access scope changed? (Yes/No): No
• If any answer is Yes, explain the risk and mitigation: N/A

Compatibility and Migration

• Backward compatible? (Yes/No): Yes
• Config or environment changes? (Yes/No): No
• Migration needed? (Yes/No): No
• If yes, list the exact upgrade steps: N/A

Review Conversations

• I replied to or resolved every bot review conversation addressed by this PR.
• I left unresolved only conversations that still need maintainer judgment.